The number homes and offices having networks continue to increase along with an ever-increasing number of networked devices within the home and/or home office. Home networking has led to the sharing of a printer among many desktop computers or the sharing of a common high-speed Internet connection, such as a cable modem connection or digital subscriber line (DSL) connection among multiple computers. Although relatively new, an ever-increasing number of home appliances are also part of a home network and may even be controlled through connections to the Internet. These factors, along with the arrival of new classes of small, intelligent, network-ready personal computing devices, including smart phones, PDAs and tablets computers, are making the home an increasingly important networking center.
The number of communication technologies used to interconnect these devices increases along with the increasing use of home networking. The Jini interface, Salutation architecture, UPnP architecture, X10, HomePlug architecture, HomePNA architecture and HomeRF technology, Bluetooth technology, HAVi technology, HiperLAN technology, the various WiFI (IEEE 802.11a/b/g) technologies, IEEE 802.15 standard interface, IEEE 1394 and, the recently proposed WiMAX architecture are only some of the various choices. Within a given technology, devices can discover and communicate with each other to share the services each provides, thereby creating compound services. However, to fully exploit the capabilities of residential networks, these diverse device networking technologies need to be coordinated so that devices between different technologies can discover and communicate with each other to provide compound services across these difference device technologies.
In response to this need, the Open Services Gateway Initiative (OSGi) defined the services gateway (An overview of the OSGI service gateway can be found in “Device and Service Discovery in Home Networks with OSGi”, by Pavlin Dobrev, David Famolari, Christian Kurzke, and Brent Miller, IEEE Communications Magazine, August 2002). The OSGi services gateway serves as a central coordination point for managing the home network, integrating the multiple heterogeneous standard device communication technologies and allowing for device interoperability. In general, the OSGi services gateway comprises an OSGi service registry and a plurality of driver bundles, each bundle corresponding, for example, to a device technology. In the OSGi environment, devices and the services they provide are represented as OSGi services and in particular, are represented as OSGi objects within the service registry, thereby making the services generally known throughout the OSGi environment. In particular, devices and services found by a native discovery technology can be imported into the OSGi framework so that they appear as registered OSGi objects, making these services and devices fully accessible by other OSGi entities. Similarly, registered OSGi devices and services can be “exported” out of the OSGi framework, so that these devices and services become discoverable using native discovery techniques of the communication technologies. This mechanism enables cross-technology discovery. In addition, the OSGi services gateway provides protocol conversions so that devices from different technologies can communicate using their native techniques. This mechanism thereby enhances interoperability across multiple device types.
The driver bundles perform this importing and exporting of devices/services and protocol conversions. In particular, a driver bundle for a given technology will discover services within that technology, transform them to the OSGi service representation, and register the service within the OSGi service registry (i.e., importing services). Similarly, the bundle will discover services that are registered in the OSGi framework that are compliant with the given technology and make these services known to its environment (i.e., exporting services). Lastly, a bundle provides conversion drivers that allow a device in one technology to use its native protocols to communicate with devices of another technology, thereby sharing services.
FIG. 1 is an exemplary network OSGi service domain 100 comprising an OSGi gateway 110 bridging a Jini network (community) 120 and an UPnP network (community) 130. The OSGi gateway 110 comprises an OSGi service registry 114, a Jini driver bundle 112 (i.e., an OSGi bundle), and an UPnP driver bundle 116 (i.e., OSGi bundle). The Jini network 120 comprises a personal computer (PC) 122 and another Jini device 124, each running the Jini communication technologies. The UPnP network 130 comprises a laptop computer 132 and another UPnP device 134, each running the UPnP communication technology. Without the OSGi service gateway, the UPnP communication technology on the laptop computer 132 and device 134 only allows the UPnP laptop to discover the UPnP device 134 and to utilize the services of that UPnP device. However, the UPnP laptop is not able to discover or communicate with the Jini device 124. A similar situation exists for the PC 122 and the Jini device 124 and UPnP device 134. The OSGI gateway 110 overcomes these issues.
Specifically, the UPnP driver 116 performs UPnP-to-OSGi transformations and OSGi-to-UPnP transformations. Similarly, the Jini driver 112 performs Jini-to-OSGi transformations and OSGi-to-Jini transformations. More specifically, the UPnP architecture introduces the control point as a device manager entity. A control point discovers newly joined devices using the information that these devices advertise. As such, when connected to a network, UPnP controlled devices multicast their presence and advertise specific services so that interested control points can detect them and subsequently use their capabilities. When a control point joins an UPnP community, it can request specific devices and services using UPnP protocols. A device can be both a control point and a controlled device at the same time.
To support the UPnP-to-OSGi transformation, the UPnP driver 116 implements the functionality of a UPnP control point, which detects newly connected devices by receiving their multicast announcements and by transmitting a discovery request to the UPnP community. The UPnP driver 116 uses the XML device description documents that are received from UPnP devices (132 and 134) to register the corresponding OSGi services by transforming the XML document to an OSGi representation.
The UPnP driver 116 also manages the OSGi-to-UPnP transformation, exporting OSGi services to the UPnP network as UPnP devices. To perform the transformation for exporting devices, the UPnP driver 116 listens for newly registered services in the OSGi service registry 114. OSGi defines a service property that specifies a service as UPnP compliant. When a new service appears in the OSGi service registry and that service has properties that identify it as compatible with the UPnP architecture, then the UPnP base driver exports information about that service to the UPnP network, using UPnP protocols. The virtual UPnP device (OSGi service) then appears in the UPnP network just like any other UPnP device.
The Jini architecture uses a Jini lookup service as the device manager entity. When devices/services are attached to the Jini community, they register themselves with the lookup service, and uploads a service object that implements all of the services interfaces for the device. When another device in the Jini community needs a service, it queries the lookup service, loads the service object, and uses the service object to communicate with the registered device.
To support the Jini-to-OSGi transformation, the Jini driver uses the Jini discovery utilities to listen for new lookup services in the Jini community. When a new lookup service appears, the driver retrieves the service object, transforms the object to an OSGi representation, and registers the service in the service registry. Similarly, the Jini driver 112 manages the OSGi-to-Jini transformation, exporting OSGi services to the Jini community as Jini devices. To perform the transformation for exporting devices, the Jini driver listens for newly registered services in the OSGi service registry. Again, OSGi defines a service property that specifies a service as Jini compliant. When a new service appears in the registry and that service has properties that identify it as compatible with the Jini architecture, then the Jini driver exports registers the service in a lookup service, making the Jini device (OSGi service) appear in the Jini community just like any other Jini device.
Accordingly, through the above mechanisms, elements within the Jini community can discover both Jini and UPnP based devices and elements within the UPnP community can discover both UPnP and Jini devices. However, the service gateway 110 and the driver bundles 112 and 116 found therein also enable the two communities to communicate using native communication technologies. Specifically, the UPnP driver 116 also implements OSGi APIs that allow other bundles (e.g., the Jini driver) on the OSGi gateway 110 (e.g., the Jini driver) to invoke the services of a UPnP device such as device 134 using standard OSGi methods. Similarly, the Jini driver 112 implements OSGi APIs that allow other driver bundles on the gateway (e.g., the UPnP driver 116) to invoke the services of a Jini device such as device 124 using standard OSGi methods. Accordingly, when the UPnP laptop computer 132 discovers the Jini device 124, it communicates with the UPnP driver 116 using native UPnP mechanisms. The UPnP driver 116 then communicates with the Jini driver 112 using OSGi mechanisms. Finally, the Jini driver 112 communicates with the Jini device 124 using native Jini mechanisms.
While the OSGi services gateway 110 allows heterogeneous devices within an OSGi domain 100 (i.e., all devices visible to the gateway) to discover and communicate with each other using native communication technologies, the OSGi services gateway 110 does not allow devices on different gateways (i.e., different OSGi domains) to discover and communicate with each other using native protocols. In addition, many of the communication technologies do not operate across the wide area (i.e., the only support communications among devices on the same local area network) and as such, devices within the same community cannot discover and communicate with one another. For example, FIG. 2 shows two OSGi service domains 200 and 250, each comprising an OSGi service gateway 210, a Jini network 220, and an UPnP network 230. Similar to FIG. 1, each Jini network 220 comprises a PC 222 and a Jini device 224 and each UPnP network 230 comprises a laptop computer 232 and an UPnP device 234. The OSGi service gateways 210 do not allow devices on the Jini and UPnP networks in the disparate OSGi service domains 200 and 250 to discover and communicate with each other. In addition, the OSGi gateways 210 do not allow devices in each Jini network community and in each UPnP community to discover and communicate with each using native communications.
Significantly, mechanisms exist that allow systems (like a PC) on an external network, such as the Internet, to control devices on local networks. However, these mechanisms have several shortcomings. In particular, the external system must know the local device exists. In other words, no discovery mechanism is available that automatically discovers the local devices. In addition, the external device and local network must have custom communication mechanisms in order to support the communications.